AMENDMENT UNDER 37 C.F.R. §1.1 14(c) 
Application No.: 10/623,621 
Attorney Docket No.: Q76494 

REMARKS 

New claim 90 is added, hence, claims 54-90 are all the claims pending in the application. 
Claims 54, 58, 63, 67, 70, 71, 72, 85 and 86 are amended. 
Specification 

The title is amended as required by the Examiner. 
Claim Rejections - 35 U.S.C. $ 101 

Claims 54-89 are rejected under 35 U.S.C. § 101 as being directed to non-statutory 
subject matter. 

Each of the independent claims is rejected for being directed to non-statutory subject 
matter because the Examiner takes the position that "locating" a fragment of metadata "does not 
appear to be a useful, concrete, and tangible result," since the Examiner alleges that "[l]ocating is 
interpreted to be an abstract idea." See paragraph 8 of the final Office Action. Claims 54, 63, 
67, 70, 71, 72 and 85 are amended to make clear that the index structure is for locating and 
extracting a fragment of metadata. This amendment is supported at least in step SI 300 of Fig. 12 
and in the discussion of Fig. 13 at page 49 of the specification. It is respectfully submitted that 
locating and extracting a fragment of metadata produces a useful, concrete, and tangible result, 
and therefore each of the independent claims is directed to statutory subject matter. 

The remaining claims rejected under §101 are directed to statutory subject matter at least 
because of their dependency from an independent claim discussed above. 
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Claim Rejections - 35 U.S.C. $ 112 

Claims 58 and 86 are rejected under 35 U.S.C. § 1 12, first paragraph, as not being 
supported by a written description. 

Claim 58 is amended and the rejection under the first paragraph of § 1 12 is believed 
obviated. 

Claim 86 is rejected as not being supported by the written description. In the Office 
Action it is asserted that the written description of the invention does not reasonably convey to 
one skilled in the art that the inventors, at the time the application was filed, had possession of 
the invention claimed in claim 86. Applicant respectfully traverses the rejection. 

Claim 86 depends from claim 85. Claim 85 is directed to an index structure for use in 
locating and extracting a fragment of metadata in which the metadata is transmitted from a 
provider to a receiver. Such an index structure, according to claim 85, includes a fragment type 
field containing an encoded value assigned to a standard fragment type. Claim 86 is amended to 
state that the encoded value is assigned to a predefined string prior to creating a container 
containing the index structure for transmission of the metadata from the provider to the receiver. 
It is respectfully submitted that person skilled in the art would understand that the inventors were 
in possession of the invention claimed in claim 86. This is because such a person would 
understand that a TV-Anytime container contains a key-index list and a string repository. See 
paragraph [12] of the specification at page 6 ("the index container carries index information 
sections such as a key index list (key_index_list) section, ... a string repository 
(string_repository) . . . .")• The skilled artisan would also clearly understand that the 
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predetermined codes, shown in Table 3 for example, which encode values for location 
information of the frequently used fragment types are defined in advance of providing a metadata 
index. See, for example, paragraph [106] and claim 19 in the originally filed application. Thus, 
the predetermined codes shown in Table 3 are assigned to the frequently used fragment types 
prior to providing a metadata index, and hence, prior to creating a container that holds the key 
index list. Accordingly, it is respectfully submitted that claim 86 is supported by the written 
description since a person of ordinary skill in the art would have understood at the time of the 
application was filed, that the inventors possessed the invention claimed in claim 86. 

Claims 58, 64 and 85-89 are rejected under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite. 

Claim 58 is amended and the rejection is believed obviated. 

Claim 64 is rejected under 35 U.S.C. § 1 12, second paragraph, as being indefinite. 
Applicant respectfully traverses the rejection. 

The Examiner asserts that claim 64 is indefinite because "the parent claim makes no 
mention of a key included within a fragment. Therefore, in line 3 of claim 64 'the key within the 
fragment' lacks antecedent basis." It is respectfully submitted that the antecedent basis for "the 
key within the fragment" is found within claim 64 itself and not in parent claim 63. 

Claim 64 is directed to the index structure as claimed in claim 63, in which "the location 
information comprises location information of a fragment including the keys and location 
information of the keys included within the fragment." Specifically, claim 64 states that the 
location information recited in claim 63 includes i) "location information of a fragment including 
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the keys," and ii) "location information of the keys included within the fragment." Accordingly, 
the location information recited in clause i) is location information for the fragment that includes 
the keys, as opposed to a fragment that does not include the keys. Hence, the location 
information recited in clause ii) is location information of the keys that are included in the 
fragment referenced in clause i). 

Since the antecedent basis for the phrase 'the keys within the fragment' is found within 
claim 64 itself, it is respectfully submitted that claim 64 satisfies the requirements of 35 U.S.C. 
§112, second paragraph. 

The Examiner asserts that the use of the word "type" in claim 85, renders the claim 
indefinite. However, the Examiner does not provide any rationale as to why the word "type" 
renders the claim indefinite. 

According to MPEP § 2173.02, "[t]he test for defmiteness under 35 U.S.C. § 1 12, second 
paragraph, is whether 'those skilled in the art would understand what is claimed when the claim 
is read in light of the specification.' Orthokinetics, Inc. v. Safety Travel Chairs, Inc., 806 F.2d 
1565, 1576, 1 USPQ2d 1081, 1088 (Fed. Cir. 1986)." See also, Metabolite Labs., Inc. v. Lab. 
Corp. of Am. Holdings, 370 F.3d 1354, 1366, 71 USPQ2d 1081, 1089 (Fed. Cir. 2004) ("The 
requirement to 'distinctly' claim means that the claim must have a meaning discernible to one of 
ordinary skill in the art when construed according to correct principles. Only when a claim 
remains insolubly ambiguous without a discernible meaning after all reasonable attempts at 
construction must a court declare it indefinite."). Cited in MPEP § 2173.02. 
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Applicant points out that the claim refers to "fragment type" and is used consistently with 
the "fragment type" described throughout the specification. See, for example, Table 2 which 
specifies "fragment Jype" in the fragment descriptor structure, and the discussion of 
"fragmentjype" in numbered paragraph [111]. Read in light of the specification, but without 
importing limitations from the specification, it is respectfully submitted that a person skilled in 
the art would understand the claim, as it is not so "insolubly ambiguous to be without a 
discernible meaning." See MPEP § 2173.02. 

If the Examiner continues to maintain that claim 85 is indefinite because it recites the 
word "type", he is respectfully requested to explain why a person skilled in the art would not 
understand the meaning of a "fragment type" especially after reading the specification. See 
MPEP § 2173.02 ("If upon review of a claim in its entirety, the examiner concludes that a 
rejection under 35 U.S.C. § 1 12, second paragraph, is appropriate, such a rejection should be 
made and an analysis as to why the phrase(s) used in the claim is 'vague and indefinite' should 
be included in the Office action."). 

Claim 86 is amended to provide antecedent basis for "predefined string" in claims 87 and 

88. 

Claim Rejections - 35 U.S.C. 8 102(a) 

Claims 54-89 are rejected under 35 U.S.C. § 102(a) as being anticipated by Evain ("1 st 
Draft of Metadata Specification SP003vl.3," XP002323574, hereinafter "Evian"). Applicant 
respectfully traverses the rejection. 
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Claim 54 is directed to an index structure for metadata divided into fragments. The index 
structure contains a list of keys and location information for defining a key and locating and 
extracting a fragment of the metadata. At least part of the location information is expressed as a 
predetermined code that is assigned to the location information according to a convention for 
associating codes with portions of the metadata. 

The Evian reference, cited in the Office Action for anticipating all of the pending claims, 
is a part of the TV- Anytime version 1.3 specification. That very same specification is identified 
in the present application as specifying the conventional key index structure. The Evian 
reference describes the conventional TV-Anytime key index list in section 2.3.2 and shows a 
diagram of it in the data structure called "key_index_list". As shown in that data structure 
diagram, the Evian key_index_list contains a "fragment_xpath_ptr" field and a "key__index__ptr" 
field. The diagram shows that each of these fields is 16 bits in length and those bits are 
identified as a "ushort". The "ushort" identifier clearly refers to a well-known designation in the 
computer arts as an unsigned short integer. Accordingly, the "fragment_xpath_ptr" and 
"key_index_ptr" fields each hold 16 bits that represent an unsigned integer. 

The Evian reference defines the fragment_xpath_ptr field as holding "an offset, in bytes, 
from the start of the string repository in the current container." Evain describes a TV-Anytime 
container as a structure that "forms the top-level storage in which all data is transmitted." An 
index container has a key index list, a string repository and a fragment data repository. See 
section 2.1 and 2.1 .2. Evian, in section 2.2.3, states that there "shall only ever be one string table 
per container" and it describes the string repository as "hold[ing] all strings used by a given 
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container." The fragment_xpath_ptr field holds an offset value corresponding to an offset from 
the beginning of the string repository at which location a string is stored. The value of that string 
in the string repository is "the Xpath to the first element of the sub-tree that the target element 
section carries." See Evian section 2.2.3. 

In the final Office Action the Examiner asserts that Evian anticipates all the pending 
claims. In particular, the Examiner asserts that the claimed feature of "the predetermined code 
being assigned to said at least a part of the location information according to a convention for 
associating codes with portions of the metadata," is taught by Evian' s "fragment_xpath_ptr " 
The Examiner points out that the fragment_xpath_ptr is "represented by at least 16 bits and a 
'ushorf identifier." See pg. 7 of the final Office Action. It is also asserted that the 
fragmentxpathjtr "is to be associated with portions of the metadata." Id. The Examiner 
further asserts that the "the code is assigned to at least part of the location information, as seen 
throughout Sec. 2.3.2." Id. Presumably, "the code" referred to is the 16 bit ushort number in the 
fragment_xpath_ptr field of Evian' s key_indexjist. 

Applicant respectfully submits that Evian' s fragment_xpath_ptr field in the 
key_index_list, is not a predetermined code assigned to at least a part of location information 
according to a convention for associating codes with portions of metadata, as required by claim 
54, for example. First, the fragment__xpath_ptr field is the field used in the conventional TV- 
Anytime key index. See numbered paragraph [17] of the specification in the present application 
("The location information of the metadata fragment is expressed in XPath (fragment__xpath__ptr) 
in the TVA."). 
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Second, the 16 bit ushort number held in the fragment_xpath_ptr field is not a code 

assigned to location information according to a convention for associating codes with portions of 

metadata. It is a number corresponding to an offset into the string repository. The fact that the 

string repository holds Xpath expressions does not make the offset into the string repository a 

code assigned according to a convention for associating codes with portions of metadata. Evian 

does not teach or even suggest that the offset value stored in the fragment_xpath_ptr would be 

determined according to a convention for associating codes with portions of metadata. Rather, 

the offset is merely a number specifying the number of rows from the beginning of the string 

repository. And that number is not assigned according to a convention for associating codes with 

portions of metadata. Rather, it is generated based on the location of the Xpath expression in the 

string repository. Evian neither teaches nor suggests that an Xpath expression is stored at any 

particular location within the string repository. In fact, the Xpath expression might appear at any 

arbitrary position within the string repository. Hence, the value of the fragment jq>ath_ptr is just 

as likely to be any offset into the string repository, regardless of the Xpath expression. The value 

of the fragment_xpath_ptr would be determined based on the location of the Xpath expression 

within the string repository and would not be assigned according to any association with the 

metadata itself. Accordingly, Evian' s conventional fragment_xpath_ptr, which merely contains 

an offset into the string repository, does not teach or suggest the limitation in claim 54 of "the 

predetermined code being assigned to said at least a part of the location information according to 

a convention for associating codes with portions of the metadata." 
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Claims 63, 67, 70, 71 and 72 also recite "the predetermined code being assigned to said at 
least a part of the location information according to a convention for associating codes with 
portions of the metadata," and hence, are not anticipated by Evian for at least the same reasons. 
Similarly, Evian does not anticipate the claims that depend from one of the independent claims 
discussed above, for at least the same reasons. 

Claim 85 is directed to an index list structure for locating and extracting a fragment of 
metadata. The index list structure includes a fragment type field and a key descriptor field. The 
fragment type field contains "an encoded value assigned to a standard fragment type specifying a 
location of the fragment." Claim 85 further specifies that "the encoded value is assigned to the 
standard fragment type according to a convention for specifying standard fragment types." 

In the final Office Action it is asserted that Evian anticipates claim 85. In addressing the 
limitations in claim 85 of the encoded value being assigned to a standard fragment type 
specifying a location of the fragment and that the encoded value is assigned to the standard 
fragment type according to a convention for specifying standard fragment types, the Office 
Action merely states "See at least sec. 2.3.1.1-2.3.2." Those portions of the Evian reference 
describe using Xpath for identifying indices and using the conventional key index list, discussed 
above. It is respectfully submitted that Evian does not teach or suggest all the limitations recited 
in claim 85. 

The Evian reference does not teach or suggest a fragment type field that contains "an 
encoded value assigned to a standard fragment type specifying a location of the fragment." As 
discussed above, the fragment_xpath_ptr field of the key index list merely contains an offset into 
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the string repository. It does not contain an encoded value assigned to a standard fragment type. 
Accordingly, Evian does not anticipate claim 85 for at least this reason alone. Further, the offset 
value contained in Evian' s fragment_xpath_ptr is not "assigned to the standard fragment type 
according to a convention for specifying standard fragment types," as required by claim 85. In 
fact, Evian does not disclose how the offset value is obtained. Assuming for the moment that the 
offset value is determined merely by calculating the location of the Xpath expression with 
respect to the beginning of the string repository, it is respectfully submitted that a person of 
ordinary skill in the art would not understand such a determination to be a convention for 
specifying standard fragment types, as required by claim 85. Accordingly, it is respectfully 
submitted that Evian does not anticipate claim 85 also for this reason. 

Evian also does not anticipate claims 87-89 because those claims incorporate by 
reference all the limitations of claim 85. 

Regarding claim 86, it is respectfully submitted that Evian does not teach or suggest the 
limitations of having the encoded value assigned to a predefined string prior to creating a 
container containing the index structure. Evian discloses a string repository in which the 
fragment location information is held. As discussed above, Evian discloses that the key index 
list contains an offset into the string repository. Evian, however, does not teach or suggest that 
the offset value into the string repository is known before creating the container since the 
location within a string repository might not be determined until the container is created. 
Accordingly, it is respectfully submitted that Evian does not anticipate claim 86 also for this 
reason. 
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New claim 90 is added which recites, "the index structure is contained in a container, the 
container having a string repository, wherein the string repository does not contain a string 
corresponding to the encoded value." Support for this limitation is found at least at paragraphs 
[104], [106], [132], [135] and Tables 2 and 3, which describe a predetermined code being 
transmitted in the key index list instead of an Xpath expression. Accordingly, since the 
predetermined code is transmitted instead of the Xpath expression, there would be no Xpath 
expression in the string repository corresponding to the predetermined code. 

In view of the above, reconsideration and allowance of this application are now believed 
to be in order, and such actions are hereby solicited. If any points remain in issue which the 
Examiner feels may be best resolved through a personal or telephone interview, the Examiner is 
kindly requested to contact the undersigned at the telephone number listed below. 

The USPTO is directed and authorized to charge all required fees, except for the Issue 
Fee and the Publication Fee, to Deposit Account No. 19-4880. Please also credit any 
overpayments to said Deposit Account. 
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